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(54) interleaving of data types in a geographic database and methods for use thereof in a 
navigation application 



(57) A geographic database for use with a naviga- 
tion application program that provides navigation fea- 
tures to an end-user. The geographic database includes 
a plurality of data records of a first type and a plurality of 
data records of a second type. The plurality of recads 
of the first type are organized into a plurality of parcels, 
each of which includes a plurality of data records of the 
first type and the plurality of records of the second type 
are organized into a plurality of parcels, each of which 
includes a plurality of data records of the second type. 
The parcels of data records of the first type are inter- 
leaved with the parcels of data records of the second 

FIG. 1 



type. This interleaving enables navigation functions that 
use these different types to access these different types 
more quicMy and efficiently, thereby enhancing naviga- 
tion system performance. Also disclosed is a method for 
forming a geographic database that includes a plurality 
of data records that represent geographic features and 
which can be used in a navigation system. The method 
includes the step of interleaving parcels containing plu- 
ralities of data records of a first type with parcels con- 
taining pluralities of data records of a second type. 
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Description 

REFERENCE TO REUTED APPLICATION 

[0001] The present appllcat'on is related to the 
copending application entKled "SEGMENT AQQREQA- 
TION IN A GEOGRAPHIC DATABASE AND METHODS 
FOR USE THEREOF IN A NAVIGATION APPLICA- 
TION" f Oed on even date herewith, the entire disclosure 
of which is incorporated tsy reference herein. 

BACKGROUND OF THE INVENTION 

[0002] The present invention relates to a system and 
method for facilitating access to and use of geographic 
data used with a navigation application program that 
provides navigating features and functions to an end- 
user, and more particularly, the present invention 
relates to a geographic database that includes geo- 
graphic data of different types, each type of which Is tai- 
lored to support one or more of the navigation functions 
and which operates with another of the different types, 
thereby facilitating certan navigation functions and 
enhancing performance. 

[0003] Computer-based navigation application pro- 
grams are available that provide end-users (such as 
drivers of vehicles in which the navigation systems are 
installed) with various navigating functions and features. 
For example, some navigation application programs are 
able to determine an optimum route to travel by roads 
between locations. Using input from an end-user, and 
optionally from equipment tiiat can determine one's 
physical location (such as a GPS system], a navigation 
application program can examine various routes 
between two locations to determine an optimum route to 
travel from a starting location to a destination location in 
a geographic region. The navigation application pro- 
gram may then provide tiie end-user with information 
about the optimum route in the form of instructions tiiat 
identify the maneuvers required to be taken by the end- 
user to travel from the starting location to the destination 
location. If tiie navigation system is located in an auto- 
nx>bile, tiie instructions may take tiie form of audio 
instructions that are provided along tiie way as the end- 
user is traveling the route. Some navigation application 
programs are able to show detailed maps on computer 
displays outiining routes to destinations, the types of 
maneuvers to be taken at various locations along the 
routes, locations of certain types of features, and so on. 
[0004] In order to provide tiiese and other navigating 
functtons. the navigation application program uses one 
or nx)re detailed databases tiiat include data which rep- 
resent physical features in a geographic region. The 
detailed database may include data representing tiie 
roads and intersections in a geographic region and also 
may include information about the roads and intersec- 
tions in a geographic region, such as turn restrk:tions at 
intersections, speed limits along tiie roads, street 



names of tiie various roads, address ranges along tiie 
various roads, and so on. 

[0005] One difficulty In provkJing geographic data for 
use by a navigation application program relates to tiie 

5 efficient utilization of the available computer resources 
of the navigation system on which the navigation appli- 
cation program is run. Computer-based navigation 
applrcatbn programs are provided on various platforms 
including some with relatively limited computer hard- 

10 ware resources. For example, navigation systems may 
be located In vehicles or may be hand-hekl. These 
types of navigation systems typically have relatively lim- 
ited computer resources, such as limited memory and 
relatively slow lyo. In order to provide a high a level of 

15 functionality in such systems, it is required tiiat the avail- 
able computer resources be used efficientiy. 
[0006] Given the relatively large size of tiie geographic 
database necessary to provide a desired level of navi- 
gating functionality to tiie end-user, it is accepted that ail 

20 the data records for an entire geographic region cannot 
be loaded into the memory of tiie navigation system at 
the same time. This is especially true for navigation sys- 
tem platforms with limited resources, such as systems 
installed in vehicles or hand-held systems. Due to tiie 

25 limited memory resources of these navigation systems, 
it Is necessary to load geographic data as needed from 
a storage medium, such as a CD-ROM disk, into tiie 
memory of tiie navigation system for use by ttie naviga- 
tion application program. Unfbrtunately, as mentioned 

30 above, in these types of systems. I/O access from a 
storage medium may also be relatively slow. Thus, tiie 
relatively limited memory resources combined witii tiie 
relatively slow I/O can limit the performance of some 
types of navigation systems, resulting in slow response. 

35 Aside from being undesirable, slow response in a navi- 
gation system may render tiie system useless for its 
intended purpose in certain circumstances. For 
ple, if tiie navigation system is installed in a vehicle, the 
driver may require information from tiie navigation sys- 

40 tern about a desired route in a matter of seconds in 
order to utilize the information while driving. If tiie navi- 
gation system requires more than several seconds to 
calculate a route, tiie driver may have moved beyond 
the point at which the routing information provided by 

45 ttie navigation system is relevant. Therefore, it is impor- 
tant that navigation systems operate efficiently in order 
to provkle navigating Information relatively quickly. 
[0007] Navigation application programs may also be 
run on computer platforms that have in general greater 

50 memory resources and faster I/O, such as personal 
computers or networks. Although these systems may 
have more and faster resources, the considerations 
related to the efficient use of geographic data stiil apply, 
but on a larger scale. With these types of systems, even 

55 greater functionality can be provided if tiie limitations 
imposed by memory size and I/O are minimized. 
[0008] Techniques have been devised or Implemented 
to improve navigation system performance by organiz- 
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ing, structuring, or arranging the geographic database 
or the data in the database in particular ways. Because 
a navigation system uses geographic data in certain 
known and expected ways to perform known functions, 
the geographic data can be organized, structured, or 5 
arranged in a manner that facilrtates their use in these 
known ways by the navigation system. 
[0009] One technique that can be implemented in a 
geographic database to enhance operatton of the navi- 
gation system is to provide separate collections or sub- 10 
sets of the geographic data for use by each of the 
separate actions in the navigation application program. 
For instance, the route calculation function normally 
uses only a portion of all the information in the geo- 
graphic database that is associated with a segment of a is 
road. When the route calculation function is being run, it 
may require information such as the speed along a road 
segment, turn restrictions from one road segment to 
another, and so on. However, the route calculation func- 
tion does not necessarily require the name of tiie road 20 
to calculate a route. Similarly, when using the map dis- 
play function, some of the information associated witii a 
road segment, such as the speed limits or turn restric- 
tions, is not required. Instead, when the map display 
function is run, it uses only a portion of the information 25 
associated with the road segment, such as the shapes 
and locations of roads, and possibly the names of tiie 
roads. Even f urtiier, when the route guidance function is 
being run, some of the inlbrmation associated with a 
segment of a road, such as the speed and turn restric- 30 
tions, is not required. Instead, when tiie route guidance 
functk>n is being run, it uses information that includes 
the name of the road represented by the road segment 
record, tiie address range abng tiie road segment, any 
signs along the road segment, and so on. Altiiough 35 
there may be some overlap as to the types of informa- 
tion used by ttie various navigation functions, some of 
the data used by any one of these navigation functions 
is not used by anotiier of the functions. If all the informa- 
tion relating to each road segment were associated with 40 
a single data entry in a single database, each data 
entity record would be relatively large. Tlius. whenever 
any one of the navigation functions accessed an entity 
record, it would have to read into memory a significant 
amount of inlbrmation much of which would not be 45 
needed by tiie navigation function. Moreover, when 
reading tiie data entity from disk, relatively few data 
entities could be read at a time since each data entity 
would be relatively large. 

[001 0] in ader to provide tiie information in tiie geo* so 
graphic database in a format more efficient for use by 
each of tiie navigation functions, separate subsets of 
the entire geographic database for a given geographic 
region are provkied for each of the different types of 
navigation functions to be provided in the navigation ss 
application program. Each of these separate subsets is 
tailored specifically fbr use by one of tiie functions. Each 
subset of data includes only the data required to be 



used by a particular navigation function. There is some 
overlap of data between each of tiiese subsets, with ttie 
result tiiat some parts of tiie information may be 
included in more tiian one subset. For example, botii 
tiie road segment data entity in ttie routing data subset 
as well as ttie road segment data entity in ttie carto- 
graphic data subset may include attributes identifying 
tiie nodes located at tiie ends of the segments. 
Although ttiis duptk^ation may result in a larger overall 
data storage requirement, each of ttie navigation func- 
tions benefits from tiie resultant effk^iency of handling 
smaller amounts of data. 

[0011] Providing for separate subsets of geographic 
data for each of the navigation functions also takes into 
account that usage of each of ttiese navigation func- 
tions relates to tiie otiiers of the navigating functions In 
expected ways. For example, an end-user may first 
mnx to view a present position, tiien enter a destina- 
tion, then receive insti'uctions how to start toward tiie 
destination, then observe a map showing the initial por- 
tion of the route, then receive further in^ructions, then 
have a map displayed of tiie next portion of tiie route, 
and so on. Because of tNs type of expected usage, 
dividing tiie data into subsets provides fbr effident use 
of the data when using each separate function. 
[0012] Atthough the division of ttie geographic data 
into subsets provkJes for efficient use of the data by 
each of the different navigation functions, it becomes 
necessary to provide ttiat ttie different navigating func- 
tions tiiat use ttiese different subsets of tiie datat>ase 
work together. For example, after an end-user obtains a 
calculated route, it may be desired to display a map on 
a computer display with the calculated route high- 
lighted. In order to accomplish tiiis, tiie routing subset of 
geographic data is accessed first to obtain the routing 
road segment data entities for ttie optimum route, and 
then ttie cartographic subset of ttie geographic data- 
base is accessed to obtain the cartographic road seg- 
ment data entities coresponding to ttie routing data 
entities. To permit these data subsets to work togettier, 
index files cross reference files, search trees, or other 
techniques may be used. Atthough tiiese techniques 
enable using these different types of data togettier, 
there may be delays associated with switching between 
these types. Accordingly, there continues to be room fbr 
Improvement in providing a geographic database for 
use witti a navigation application. 

SUMMARY OF THE INVENTION 

[0013] To address tiie above concerns, according to 
one aspect of the present invention, tiiere is provided a 
geographic database for use with a navigation applica- 
tion program ttiat provides navigation features to an 
end-user. The geographic database includes a plurality 
of data records of a first type and a plurality of data 
records of a second type. The plurality of records of tiie 
first type are organized into a plurality of parcels, each 
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of which includes a plurality of data records of the first 
type. The plurality of records of the second type are 
organized into a plurality of parcels, each of which 
includes a plurality of data records of the second type. 
The parcels of data records of the first type are inter- 
leaved with the parcels of data records of the second 
type. This interleaving enables navigation functions that 
use these different types to access these different types 
more quicldy and efficiently, thereby enhancing naviga- 
tion system performance. 

[0014] Also disclosed is a method for forming a geo- 
graphic database that includes a plurality of data 
records that represent geographic features and which 
can be used in a navigation system. The method 
includes the step of interleaving parcels containing plu- 
ralities of data records of a first type with parcels con- 
taining pluralities of data records of a second type. 
[001 5] The data types that can be interleaved can be 
any types, such as routing data, cartographic data, 
maneuvering data, point of interest data, and so on. The 
kind of interleaving can be selected to facilitate the per- 
formance of certain navigation functions. The kinds of 
interleaving include single alternating order, spatial 
ordering, and custom ordering, as well as other kinds. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] 

Figure 1 is a block diagram illustrating a navigation 
system. 

Figure 2 illustrates a map showing a geographic 
region represented by the geographic database of 
Rgurel. 

Figure 3 shows an expanded view of a portion of 
the map of Figure 2. 

Figure 4 is an illustration of a single road segment 
shown in the map of Rgure 3. 
Figure 5 is a diagram illustrating the different types 
of data included in the geography database of Fig- 
ure 1 for use with various navigatton application 
functions. 

Figure 6 is a diagram illustrating separate layers of 
data in the routing data shown in Rgure 5. 
Figure 7 shows a map of the geographic region of 
Figure 2 illustrating application of a parcelization 
method to spatially organized geographic data. 
Figure 8 is a diagram showing the arrangement of 
parcels of data in the geographic database of Fig- 
ure 1 according to the parcelization method illus- 
trated in Figure 7. 

Figure 9 is a diagram showing the arrangement of 
segment and node data records within a single par- 
cel of the database of Figure 8. 
Figures 10A though 10D graphically illustrate the 
geographic features represented by aggregated 
segment data records. 

Figure 11 is a diagram illustrating inclusion of 



aggregated segment records in a parcel of routing 
data in layer above layer 0. 
Rgure 12 is a diagram illustrating the components 
of an aggregated segment record and its associ- 

5 ated abbreviated record array of Rgure 1 1 . 

Rgure 13 is a diagram illustrating ttie components 
of the abbreviated segment record of Figure 12. 
Rgure 14 is a diagram illustrating the components 
of the abbreviated node record of Figure 12. 

10 Rgure 1 5 is a diagram illustrating tiie kinds of infor- 
mation included in a segment record included in 
layer 0>3 of ttie routing data. 
Rgure 16 is a diagram illustrating inclusion of 
aggregated segment records in a parcels of a layer 

IS of routing data according to an alternative embodi- 
ment. 

Rgure 17 is a diagram illustrating ttie components 
of an aggregated segment record and its associ- 
ated abbreviated record array of Rgure 16. 
20 Rgure 18 is a diagram representing one anrange- 
ment for interleaving different types of data witiiin a 
layer of data. 

Rgure 19 is a diagram representing another 
arrangement for interleaving different types of data 
25 wittiin a layer of data. 

Rgure 20 is a diagram representing still another 
arrangement for interleaving different types of data 
within a layer of data. 

Rgure 21 is a diagram illustrating ttie steps in fbrm- 
30 ing a geographic database having a portion with dif- 
ferent data types interleaved witii each ottier, as 
shown in Figure 20. 

Rgure 22 is a diagram of a map illustrating ttie 
application of a parcelization step in Figure 21 to 
35 geographic data that represent features in the illus- 
tiBted region. 

Rgure 23 is a diagram of a kd-tree ttiat corresponds 
to the parcelization step illustrated in Figure 22. 

40 DETAILED DESCRIPTION OF THE PRESENTLY PRE- 
FERRED EMBODIMENTS 

I. NAVIGATION SYSTEM - OVERVIEW 

45 [001 7] Refening to Figure 1 , tiiere is a block diagram 
of a navigation system 10. The navigation system 10 is 
installed in a vehicle 1 1 , such as a car or ti^uck, aKhough 
in alternative embodiments, ttie navigation system 10 
may be located outside of a vehicle or may be imple- 

so mented in varbus ottier platforms or environments, as 
described below. 

[001 8] Referring to ttie embodiment illustrated in Fig- 
ure 1, tiie navigation system 10 is a combination of 
hardware and software components. In one embodi- 
55 ment, ttie navigata'on system 10 Includes a processor 
12. a drive 14 connected to the processor 12, and a 
non-volatile memory storage devk;e 16 fbr storing a 
navigation application software program 18, possibly as 
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well as other information. The processor 12 may be of 
any type used in navigation systems, such as 32-bit 
processors using a fiat address space, such as a 
Hitachi SHI, an Intel 80386, an Intel 960. a Motorola 
68020 (or other processors having similar or greater 5 
addressing space). Processor types other than these, 
as well as processors that may be developed in the 
future, may also be suitable. 
[0019] The navigation system 10 may also include a 
positioning system 24. The positioning system 24 may 10 
utilize GPS-type technology, a dead reckoning-type sys- 
tem, or combinatior^ of these, or other systems, all of 
which are known in the art. The positioning system 24 
may include suitable sensing devices 25 that measure 
the traveling distance speed, direction, and so on, of the is 
vehicle. The positioning system 24 may also include 
appropriate technology to obtain a GPS signal, in a 
manner which is known In the art. The positioning sys- 
tem 24 outputs a signal 26 to the prociessor 1 2. The sig- 
nal 26 may be used by the navigation application 20 
software 1 8 that is run on the processor 1 2 to detennine 
the location, direction, speed, etc.. of the navigation 
system 10. 

[0020] The navigation system 1 0 also includes a user 
interface 31 . The user interface 31 includes appropriate 25 
equipment that alk>ws the end-user to input information 
into the navigation system. This input information may 
include a request to use the navigation features of the 
navigation system. For example, the Input information 
may include a request for a route to a desired destina- 30 
tion. The input Information may also include other kinds 
of information. The equipment used to input information 
Into the navigation system may include a keypad, a key- 
board, a microphone, etc.. as well as appropriate soft- 
ware, such as a voice recognition program. The user 35 
interface 31 also includes suitable equipment that pro- 
vides information back to the end-user. This equipment 
may include a display 27, speakers 29, or other means. 
[0021] The navigation system 10 uses a map data- 
base 40 stored on a storage medium 32. The storage 40 
medium 32 is installed in the drive 14 so that the map 
database 40 can be read and used by the navigation 
system. The storage medium 32 may be removable and 
replaceable so that a storage medium with an appropri- 
ate map database for the geographic region in which the 45 
vehicle is traveling can be i^ed. In addition, the storage 
medium 32 may be replaceable so that the map data- 
base 40 on it can be updated easily. In one embodi- 
ment, the geographic data may be published by 
Navigation Technologies of Sunnyvale. California. so 
[0022] In one embodiment, the storage medium 32 is 
a CD-ROM disk. In an alternative emtxxliment, the stor- 
age medium 32 may be a PCMCIA card in which case 
the drive 14 would be substituted with a PCMCIA slot 
Various other storage media may be used, including ss 
fixed or hard disks. DVD (digital video disks) or other 
currently available storage media, as well as storage 
media that may be developed in the future. The storage 



medium 32 and the geographic database 40 do not 
have to be physically provided at the location of the nav- 
igation system. In alternative embodiments, the storage 
medium 32. upon which some or all of the geographic 
data 40 are stored, may be located remotely from the 
rest of the navigation system and portions of the geo- 
graphic data provided via a communications link, as 
needed. 

[9023] The navigation application software program 
18 is loaded from the non-volatile memory 16 into a 
RAM 20 associated with the processor 12 in order to 
operate the navigation system. The navigation system 
10 uses the map database 40 stored on the storage 
medium 32. possibly in conjunction with the output 26 
from the positioning system 24. to provide various navi- 
gation features and functions. The navigation applica- 
tion software program 18 may include separate 
applications (or subprograms) that provide these vari- 
ous navigation featores and functions. These functions 
and features may include route calculatfon, map display, 
vehicle positioning (e.g., map matching), route guid- 
ance (wherein detailed directions are provided for 
reaching a desired destination), destinatfon resolution 
capabilities, and other functions. 

11. GEOGRAPHIC MAP DATABASE 

a. Overvie w. 

[0024] . In one present embodiment, the speed and/or 
functionality of a navigation system can be enhanced by 
a combination that includes improvements in the stor- 
age, anrangement and/or structuring of the geographic 
data used by the system to bdlitate the use of the data 
by some of the functions in the navigatfon application 
program in the systems that use the data. Based upon 
the manner in which the geographic data are stored 
arranged, and/or structured, functions in the navigation 
application program tiiat access and use the data can 
implement routines that exploit the Improvements incor- 
porated into the geographic data. This combination can 
result in overall improved performance by the navigation 
system. 

[0025] The map database 40 contains information 
about the roadway network in the geographic region. In 
one embodiment the map database 40 includes node 
data and segment data. Node data represent physical 
locations in the geographic region (such as roadway 
intersections and otiier positions) and segment data 
represent portions of roadways between the physical 
locations represented by nodes. Each road segment in 
tiie geographic region is represented by a road segment 
data entity (i.e., a record) in the map database 40. Each 
road segment data record in the map database has two 
nodes which represent the coordinate positions at each 
end of the road segment represented by the road seg- 
ment data record. The information Included in the node 
and segment data entities is explained with reference to 
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Figures 2 and 3. (TTie terms "nod^" and "segments" 
represent only one terminology for . describing these 
physical geographic features and other terminology for 
these features is intended to be encompassed within 
the scope of these concepts.) s 
[0026] Rgure 2 illustrates a map 1 1 0 showing a geo- 
graphic region 112. A plurality of locations 114 are 
shown to be located in the geographic region 1 12. Each 
of the locations 1 14 represents a place or point in the 
geographic area 1 1 2 at which there is focated a feature io 
about which it Is desired to include information in a geo- 
graphic database. Each of these locations 114 has a 
unique physical location (latitude, longitude, and option- 
ally absolute or relative altitude) and each of the loca- 
tions 114 can be uniquely identified by its two is 
dimensional (or three dimensional) geographic coordi- 
nates, (i.e.. latitude, longitude, and optionally altitude). A 
location 1 14 may correspond to an intersection at which 
two or more roads meet, a point along a road segment 
at which the direction of the road changes, a point along so 
a road segment at which the speed limit changes, a 
point at which a road reaches a dead end. and so on. 
The location 114 may correspond to a position of a 
point^of interest, such as a hotel or civic center, a 
boundary of a natural feature, such as a lake, or a posi- 25 
tion along a railroad track or fen'y. The locations 114 
may con^espond to anything physically located in the 
geographic area 112. 

[0027] Figure 3 shows an expanded view of a portion 

116 of the map 110. The portion 116 in Figure 3 illus- 30 
trates part of the road network 120 in the geographic 
region 112. The road network 120 includes, among 
other things, roads and intersections located in the geo- 
graphic region 112. As shown in Figure 3 in the illus- 
trated portion 116 of the map 110. each road in the 35 
geographic region 1 1 2 is conposed of one or more seg- 
ments. 122(1), 122(2)... I22(n). In one embodiment, a 
road segment represents a portion of the road. In Figure 
3. each road segment 122 is shown to have associated 
with it two nodes 123: one node represents the point at 40 
one end of the road segment and the other node repre- 
sents the point at the other end of the road segment. A 
single road segment 122 and its two associated nodes 
123(a) and 123(b) are illustrated in Figure 4. The node 
at either end of a road segment may conrespond to a 45 
location at which the road meets another road. e.g., an 
intersection, or where the road dead ends. (An intersec- 
tion may not necessarily be a place at which a turn from 
one road to another is permitted, but represents a loca- 
tion at which one road and another road have the same so 
latitude and longitude.) 

[0028] In addition, if the road segment 122 is other 
than straight (e.g., it bends, tums, etc.). the road seg- 
ment 122 may include one or more shape points 124 
between its end points 123. Shape points 124 provide ss 
geographic positions (i.e.. latitudes, longitudes, and 
optionally, altitudes) along the length of the road seg- 
ment to accurately represent the true physical tocations 



of the road segment along its length. Shape points 124 
are used to assist in vehicle positioning, map display, 
etc. 

[0029] In one type of geographic database, there is at 
least one database entry (also referred to as "entity" or 
"record") for each road segment represented in a geo- 
graphic region. This road segment data record may 
have associated with it information (such as "attributes*, 
llelds", etc.) that allows identiflcatfon of the nodes 
associated with the road segment and/or the geo- 
graphic positions (e.g. the latitude and longitude coordi- 
nates) of the two nodes. In addition, the road segment 
record may have associated with it information (e.g.. 
more "attributes'*, fields", etc.), that specify the speed 
of travel on the portfon of the roadway represented by 
the road segment record, ttie direction of travel permit- 
ted on the road portion represented by the road seg- 
ment record, what if any turn restrictions exist at each of 
the nodes which correspond to intersections at the ends 
of the road portion represented by the road segment 
record, the street address ranges of the roadway por- 
tion represented by the road segment record, tiie name 
of ttie road, and so on. Each segment data entity ttiat 
represents an other-than-straight road segment may 
include one or more shape point data attributes that 
d^ine the other-than-stralght shape of the road seg- 
ment. The various attributes assodated with a road seg- 
ment may be included in a single road segment record, 
or preferably are included In more than one type of road 
segment record which are cross-referenced to each 
other. 

[0030] In a geographic database that represents ttie 
region 112. there may also be a database entry (entity 
or record) for each node in ttie geographic region. The 
node data record may have associated with it informa- 
tion (such as "attributes", "fields', etc.) that allows iden- 
tification of ttie road segment(s) that connect to It and/or 
its geographic position (ag., its latitude and longitude 
coorcfinates). 

b. Separate su bsets of aeoar^hic data 

[0031 ] As mentioned above, one way tiiat tiie access- 
ing of geographic data can be enhanced for performing 
various navigation functions is to provide separate col- 
lections or subsets of ttie geographic data for use by 
each of the separate functions in the navigation applica- 
tion program. Figure 5 illustrates tiie geographic data- 
base 40 comprised of separate routing data 136, 
cartographic data 137 (for map display), maneuver data 
138 (for route guidance) .'and point-of-interestdata 139. 
A geographic database may be defined with fewer or 
more siissets ttian these, and ottier types of data may 
be defined and included. To permit these data subsets 
to work together, index files 140 are included ttiat pro- 
vide cross references, search t^ees, or other data find- 
ing techniques. 
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c, LavGrina ofaeoaraDhic data 

[0032] Another way that the geographic data can be 
organized to enhance their use is to provide the data in 
layers. Some of the navigation functions, such as the s 
map display function and the route calculation func- 
tions, may use data at different levels of detail. For 
example, when using the map display function, it is 
sometimes desired to provide for panning and zooming. 
Zooming can be done more efficiently if the data are io 
organized into layers, with greater detail at the lower lay- 
ers and less detail at the higher layers. When using the 
route calculation function it is also advantageous to use 
the data at different levels of detail. For example, when 
calculating a route between two locations, it would he is 
Inefficient to examine all the possible road segments 
that diverge from each intersectbn along the route, 
including secondary streets and alleys. Instead, once a 
route is "on** a main road a expressway, it is generally 
preferable to slay on main roads or expressways until rt 20 
is necessary to exit to secondary roads as the destina- 
tion is approached. If the routing data are layered, 
higher layers that omit secondary roads can be used 
when possible to minimize the possible road segments 
to be investigated when calculating the route. Therefore, 25 
within some of the subsets of data types, the geo- 
graphic data are provided in separate collections or 
groups corresponding to separate layers. 
[0033] To implement layering, each road segment 
data record in the map database 40 also identifies the 30 
rank of the corresponding portion of the roadway that it 
represents. A rank of a road segment may correspond 
to its functional class. Road segments having a rank of 
"4" may include high volume, controlled access roads, 
such as expressways and freeways. Road segments 35 
having a rank of "3" may be high volume roads with few 
speed changes, but are not necessarily controlled 
access roads. The lower ranked roads handle corre- 
sponding lower volumes and generally have more 
speed changes or sbwer speeds. Road segments hav- 40 
ing a rank of "0" can handle the lowest volumea For 
example, these may include side streets, alleyways, etc. 
[0034] The rank of a road segment data entity also 
specifies the highest data layer in which a road segment 
entity is included. For example, referring to Figure 6, the 45 
routing type data 136 may include five separate layers 
of the data. RO. R1 . R2. R3. and R4, each comprising a 
separate collection of the routing data with a different 
level of detail which can be used by the route calculation 
function. In tiie routing data type of the geographic data- so 
base, layer 0 ("RO)** includes the road segment data 
entities (and some or all of their corresponding routing 
data attributes) having a rank of "0" or higher. Thus, 
layer 0 includes road segment data entities correspond- 
ing to all the portions of all tiie roads in tiie geographic ss 
region. Layer 1 of tine routing data 1 37 comprises a sep- 
arate siJt>set (or collection) of tiie routing data and 
includes only the routing segment data entities (and 



some or all of their corresponding routing data 
attributes) having a rank ofT a higher. Layer 2 of tiie 
routing data comprises a separate subset of the routing 
data and includes only the routing segment data entities 
(and some or all of their conesponding navigation data 
attributes) having a rank of level 2 or higher, and so on. 
A highest layer (layer n) includes only records having a 
rank of n. In a present embodiment, n is equal to 4, 
although in other embodiments, n may be any number 
greater than 0. Each higher layer includes fewer 
records, however these records represent roads upon 
which travel is generally faster. 
[0035] Similarly, the other types of data, such as tiie 
cartographic subset type 1 37 may include separate col- 
lections of the data, each with a different level of detail, 
which can be used by the map display function. Using 
fliese different layers of cartographic data, the map dis- 
play function can provide rapid panning and zooming. 
[0036] Although the organization of some of the data 
into layers results in some duplication of the data, the 
increased efficiency provided by layering generally off- 
sets any disadvantages. As with ttie use of separate 
types of data menttoned above, tiie need arises to allow 
tiiese layers to work togetiier. The index files 140, which 
include cross references, search trees, or otiier finding 
techniques, may be provided fa this purpose. 

d Soatial access to geogrf^pht data 

[0037] Organizing the data into subsets or types and 
layering the data of some of the types provide separate 
collections of the data in sizes that are more managea- 
ble by each of the navigation functions. Witii respect to 
some subset types and layers of these types, the data 
can be furtiier organized to facilitate spatial access. 
[0038] Several of the navigation functions provkied in 
a navigation system may require access to the geo- 
graphic data spatially. One way this arises is that a func- 
tion in a navigation application program requires finding 
a data entity record in a geographic database given the 
physical location represented by ttie data entity in the 
geographic region. The data entity may be a road seg- 
ment record that represents a portion of a road in the 
geographic region and ttie function may require finding 
tiie road segment record based upon the physical loca- 
tion in the geographic region of the portion of the road 
represented by the road segment record. Another way 
spatial access arises is when a function in a navigation 
application program requires finding several or all of a 
type of data records located close to a location in the 
geographic region or within a defined area in the geo- 
graphic region. For example, a function may require all 
road segment records tiiat represent road segments 
encompassed within a rectangle defined by geographi- 
cal coordinates (x, x+n) latitude and (y, y+m) longitude. 
[0039] Assuming ttiat all the data records for a given 
entire geographk; region cannot be loaded into memory 
at ttie same time due to limited memory resources of 
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the navigation system In which the navigation applica- 
tion program is heing run. it would be desirable to load 
into memory only those data that are needed. Since 
some of the navigation functions require accessing (feita 
spatially, it would be advantageous to provide a means 5 
to load data into memory based generally upon the 
physical geographic locations of the features which the 
data represent or upon the geographical proximity of the 
features which the data represent. This can be provided 
by organizing the data so that they are located in the w 
database and/or on the medium based upon the geo- 
graphic locations of the features which are represented 
by the data. Various techniques can be used to provide 
for spatial access. One l«nd of technique, parcellzation. 
is described below. f5 

e. Pafcelization. 

[0040] Parcellzation is included among the techniques 
that can be used to facilitate the use of geographic data 20 
by navigation systems. Assuming that all the data 
records for a given entire geographic region cannot he 
loaded into the memory of the navigation system at the 
same time, due to limited memory resources of the nav- 
igation system in which the navigation application pro- 25 
gram Is being run, It would be desirable to load Into 
memory only those data that are needed to perform a 
desired function. In order to accomplish this, data in the 
geographic database 40 are organized in a nfianner that 
minimizes the number of times that the medium must he so 
accessed and read in order to perform a navigation 
function. To provide for this, the data are organized into 
parcels. When data are parcelized, the plurality of data 
records that together comprise the geographic data are 
grouped together Into separate groups or parcels. A 3S 
parcel of data is established to contain data that are 
always accessed together. This may relate to the quan- 
tity of data that can be accessed In a single disk access, 
although it may be related to some other factor. For 
some types of media such as a CD-ROM disk, a parcel 40 
may be established to be a 16 Kilobyte quantity of data. 
(Other sizes of data may he used including 1 K. 2 K, 4 
K, 8 K, 32 K, and so on. The portions of the geographic 
database are generally fbnned in sizes of 2" Kilobytes, 
wherein n is an integer value greater than 1 .) 45 
[0041] Parcellzation can he used in conjunction with 
spatial access to facilitate the use of data to enhance 
performance of the navigation system. When geo- 
graphic data are organized spatially, features that are 
close together physically in the geographic region are so 
represented by data records that are physically (or logi- 
cally) close together In the database. Geographic data 
can be both parcelized and spatially organized to take 
advantage of both these techniques. 
[0042] F=br purposes of forming the data into parcels, ss 
the data may be first separately organized into different 
types such as routing 136, cartographic 137, maneuver 
138, points of interest 139, and so on. Some of these 



kinds of data may be parcelized spatially In order to 
fadlitate use of the data by the navigation functions and 
others of these kinds of data may not be parcelized spa- 
tially. Spatially-parcelized data are arranged so that the 
data that represent geographically proximate features 
are located logically and/or physically proximate in the 
database 40 and/or on the medium 32. For some of the 
navigation application functions, spatial parcellzation of 
their respective data provides for reading closely related 
geographic data from the medium more quickly and 
loading related geographic data into memory where 
they can be used. TTiis kind of organization minimizes 
accessing of the storage medium 32 and may speed up 
operation of these navigation functions. The routing 
data 136 (in Figure 5) are included among the kinds of 
data that may be spatially organized. 
[0043] There are a number of different procedures 
that can be used for parcelizing spatially organized geo- 
graphic data. For example, a simple parcellzation 
method may provide for separating the geographic data 
into a plurality of parcels or groupings wherein the data 
in each parcel represent features encompassed within a 
separate one of a plurality of regular sized rectangles 
which together form a regular, rectangular grid over the 
geographic region. Another method for parcellzation is 
to separate the data into parcels encompassed within 
rectangular areas where each of the rectangles is 
formed by a bisection of rectangles encompassing parts 
of the region until a parcel size below a maximum 
threshold is obtained. In addition, parcellzation proce- 
dures are disclosed In the copending application Ser. 
No. 08/740,295. filed October 25. 1996, the entire dis- 
closure of which is incorporated by reference herein, 
and parcellzation procedures are also described in the 
copending patent application Ser. No. 08/935.809. filed 
September 5, 1997, the entire disclosure of which is 
incorporated by reference herein. Still anotiier method 
of parcellzation to which the disclosed subject matter 
can be applied is described In U.S. Pat. No. 4,888,698. 
IP044] Parcelizatton of spatially organized data Is illus- 
trated witii reference to Figures 7-9. Figure 7 shows the 
map 1 10 of the geographic region 112, prevtously lllus- 
tinted in Figure 2. The plurality of positions 1 14 (repre- 
sented by tiie dots or points) are shown to be located on 
ttie map 110. In Figure 7, a grid 217 overlays the geo- 
graphic region 112 represented by the map 110. The 
grid 217 divides the geographic region 1 12 into a plural- 
ity of rectangular areas 219. The grid lines of tiie grid 
217 represent tiie boundaries of rectangular areas 219. 
These rectangular areas 219 may be all the same size 
or may have different sizes depending upon tiie proce- 
dure used for parcellzation. Likewise, tiie locations of 
tiie boundaries may depend on tiie parcellzation proce- 
dure used. In general, when using any of the proce- 
dures for spatial parcellzation. the data records of a 
particular type of data which represent features that are 
enconpassed within each rectangular area 219 are 
grouped together in a separate parcel of data. Referring 
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to Figures 8 and 9, the plurality of data records, such as 
the road segment records 322 and the node records 
323 that comprise the geographic database 40. are col- 
lected into separate groupings called parcels 220. With 
respect to the spatially organized data, each parcel 220 $ 
in Figures 8 and 9 Includes one or more data records 
322, 323. which represent the geographic features 
encompassed within a separate one of the plurality of 
rectangles 219 shown in Figure 7. 
[0045] As shown in Rgures 8 and 9, the parcels 220 io 
are stored to form the database 40 so that the data in 
each parcel 220 are logically and/or physically grouped 
together. A parcel 220 may represent the physical quan* 
tity of data that can be accessed at a time by the navi- 
gation system. When a parcel of data is accessed, all of i5 
its data records 322, 323, are read from the medium into 
the memory of the navigation system at the same time. 
With reference to the map 110 of Figure 7. this means 
that all the data records such as the segment records 
322 or node records 323. of a spatially organized type of 20 
data encompassed within each rectangle 219 are 
accessed together as a group. It can be appredated 
that for certain Kinds off navigation functions, it is desira- 
ble to have in memory at the same time all the data 
records ttiat represent features that are physically close 25 
together In the geographic region. 
[0046] As the parcels 220 are formed for these types 
of data, the parcels are ordered. Various types of order- 
ing may be used. In general, it Is pretended that the par- 
cels be ordered in a manner that minimizes searches for 30 
data. One way to order spatially organized parcels is to 
use a depth-first ordering from a kd-t'ee index within 
each type of data. This provides an ordering similar to 
Peano-key ordering. Parcels may be stored on disk (i.e.. 
medium 32 in Figure 1) in this approximate Peano-key 35 
order. One or more indices, such a kd-t-ee, can be used 
to access parcels spatially This index is useful for initial 
location of an arbitrary position, such as when a pro- 
gram in a navigation system initially bcates the map 
data corresponding to a current vehrcle position. As the 40 
parcels 220 are ordered, each may also be assigned a 
unique parcel identifier (e.g.. a "parcel ID"). TTie parcel 
ID may be used to identify the parcel and/or its location 
on the medium. 

[0047] (As mentioned above, some kinds of data are 4s 
not spatially organized. Each parcel of non-spatially 
organized data does not necessarily correspond to any 
of the rectangular areas 219 in Rgure 7. For example, 
data that represents the names of streets may be 
organized alphabetically instead of spatially.) so 

III SEGMENT AGGREGATION 

a. Overview. 

55 

[0048] In a present embodiment, tiie geographic data- 
base Includes data records tiiat represent aggregations 
of road segments. These data records ttiat represent 



aggregations of segments of roads are included in the 
database in addition to the data records (e.g.. 322 in 
Figure 9) tiiat represent tiie separate road segments 
from which tfie aggregations are formed. Using data 
records that represent aggregations of roads has ttie 
potential to provMe several advantages. Using records 
tiiat represent aggregations of segments of roads may 
reduce the number of road segments that need to be 
explored during route calculation. It is also possible that 
if records tiiat represent road segment aggregations are 
used, ttie number of segments that make up a final cal- 
culated route may he reduced tiiereby improving navi- 
gation system performance. In addition, it is also 
possible tiiat if records tiiat represent road segment 
aggregatior^ are used, the overall size of tiie database 
may be reduced. 

[0049] One way to form data records tiiat represent 
aggregations of segments of roads derives from tiie for- 
mation of mult^le layers of data in the database. As 
mentioned above, a road segment data entity includes a 
rank attribute that corresponds to a functional classifica- 
tion of tiie represented road segment. In a present 
embodiment, the rank atb'ibute is used to form layers of 
tiie geographic datat}ase. TTie rank attribute specifies 
tiie highest data layer in which the road segment is rep- 
resented. The lowest layer. i.e.. "RO". of the route calcu- 
lation data 136 includes all routing road segment 
records (i.e., road segment records of all ranks). In each 
succeeding higher layer, tiie lowest-ranked road seg- 
ment records are omitted. As a result, these higher lay- 
ers include a number of "bivalent" nodes, i.e. nodes 
between at which exactly two segments meet or inter- 
sect. (It is also possible to form bivalent nodes under 
otiier circumstances in tiie geographic database, for 
example when a road segment crosses an administra- 
tive boundary) If atfa'ibutes that are relevant to route cal- 
culation are tiie same for the two road segment records 
that are joined by a bivalent node, an aggregated seg- 
ment record can be formed that suppresses or drops 
the bivalent node. 

fa Physical represents^ion of aaareaated seanjents. 

[0050] Rgure 1 0A is an illusti^ation of a plurality of road 
segments 122 which are represented by road segment 
records in layer 0 of ttie routing data 136. A node 123 is 
associated with each of tiie end points of each of the 
road segments 122. In layer 0, all the road segments of 
all the ranks are represented by data entities. Figure 
10B shows tiie same plurality of segments 122 and 
nodes 123 shown in Figure 10B, except tiiat the road 
segments having a rank of "0" are illustrated in dashed 
lines. Rgure IOC shows these lower ranked road seg- 
ments removed. (Figures 10B and IOC illustrate inter- 
mediate stages and are not representative of a layer.) 
Figure IOC illustrates tiie segments 122 and nodes 123 
in layer 1. As illustrated in Figure IOC. elimination of 
road segments having a rank of 0 results in some 
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remaining nodes joining only two road segments. It may 
be possible to speed up route calculation if little or no 
calculation is performed when calculating a route that 
traverses these kinds of nodes. To take advantage of 
this arrangement, the segments 122 (labeled SI, S4. 5 
S5, S6, S7, S9, and S1 1) are represented by an aggre- 
gated segment record which is fonmed and stored in the 
geographic database 40. This aggregated segment 
record represents the aggregation, labeled AG12, of the 
separate road segments, as shown in Figure 1 0D. 10 

c. Agareaaibn Criteria, 

[0051 ] Figures 1 0A-1 CD illustrate the conditions under 
which It is possible to form an aggregated segment is 
record. According to one alternative embodiment, 
aggregated segment records are always formed when- 
ever two and only two road segments are joined by a 
single node. However, under some circumstances, it 
may be preferable to refrain from forming an aggregated 20 
segment record under these conditions. For example, if 
certain attributes of adjacent road segments differ. It 
may be preferable not to form an aggregated segment 
record to represent them in aggregation even if they are 
the only road segments joined by single node. Thus, 25 
according to an alternative embodiment, attributes of 
adjacent road segment records are examined to deter- 
mine whether the represented road segments are simi- 
lar enough to be represented by an aggregated 
segment data record. Various criteria may* be used for 30 
making this determination. For example, in one alterna- 
tive embodiment, it may be required that all attributes in 
adjacent road segments be the same in order to fomi an 
aggregated segment record. In another alternative 
embodiment, it may be required that only certain 35 
attributes be the same in adjacent road segments to 
form an aggregated segment record. In this latter alter- 
native, some attributes may be permitted to differ 
between adjacent road segments. 
[0052] In one present embodiment an aggregated 40 
segment record is formed where each consecutive pair 
of adjoining road segments has the same name, rank, 
speed category, lane category, and access characteris- 
tics, among other characteristics. However, formation of 
an aggregated road segment is not pemiitt^ if the 45 
adjacent road segments include a restricted driving 
nianeuver, a vehicle restriction; a direction of travel 
restriction, a gate, a high-occupancy-vehide restriction, 
a bifurcated roadway, a toll booth or signage, among 
other restrictions so 
[0053] TTie above criteria only represent examples of 
the kinds of attributes that may be evaluated to deter- 
mine whether an aggregated segment record is formed 
from two or more adjacent segments. Other criteria may 
be suitable. ss 



d Process for forming aaareaated SGaments, 

[0054] When fomilng aggregated segment records 
using any embodiment that requires an evaluation of 
whether the adjacent road segments meet some crite- 
ria, the first step is to identify possible end nodes for 
aggregated road segments. These may be refenred to 
as "aggregated-segment-significant" nodes. Every 
node in the geographic database at each of the layers is 
evaluated to determine whether it is an aggregated-seg- 
ment-slgnificant node. The nodes are evaluated one at 
a time, starting at the highest layer and working down. A 
node is "aggregated-segment-significanf at a given 
layer when only one road segment, or more than two 
road segments, are connected to it However, if exactty 
two road segments are connected to a node, the node 
may not be aggregated-segment-signif icant. If a node is 
determined to be aggregated-segment-signlficant at a 
given layer, it is aggregated-segment-significant at all 
lower layers. Each road segment in a layer that has an 
aggregated-segment-significant node on one end and a 
non-significant node on the other end is a potential 
starting end for an aggregated segment. 
[0055] In Figure 10C, nodes N102 and N112 are 
aggregated-segmerit-significant since they connect to 
more than two segments. Nodes N104, N106, N107. 
N108, N109, and N113 may be non-significant since 
they connect to two and only two segments. Segment 
81 is identified as a potential starting point for an aggre- 
gated segment since it has one node. N112, that is 
aggregated-segment-significant, and tiie other node, 
N1 09 tiiat may be non-significant. Unless there is a con- 
dition. sign, or some other attribute change on 81. the 
node N112 can be used as tiie starting point for an 
aggregated segment. The node N 109 on the other end 
of segment 31 is evaluated according to tiie applicable 
criteria to determine whether it is a significant node. If it 
is not a significant node, the node N109 is a potential 
internal node for an aggregated segment. Then, tiie 
other segment oonn^ied to the node N109, i.e., 84 in 
Figure 10C. is evaluated (1) to determine whether its 
otiier node. N108, is aggregated-segment-significant, 
and (2) to check whether tiie other aggregation criteria 
are met. This process continues until an aggregated- 
segment-significant node is reached or until a node is 
reached tiiat would otherwise be non-significant but 
which connects two segments ttiat have differing condi- 
tions that disqualify them from being aggregated. These 
conditfons are described above. If a node which would 
otiienvise be non-significant connects two road seg- 
ments having differing conditions that disqualify tiiem 
from being aggregated, the node is denominated as an 
aggregated-segment-significant node for that rank and 
lower. 

[0056] It is noted ttiat the above method produces an 
aggregated segment that has aggregated-segment-sig- 
nificant nodes at its ends and at least one non-signifi- 
cant node between the ends. However, not all 
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aggregated-segment-slgnificant nodes within a layer 
are necessarily located at end points of an aggregated 
segment 

e. Location of aQareasted segment records. s 

[0057] Once a string of road segments (between two 
aggregated-segment-slgnificant nodes) are identified 
that connect to each other non-significant nodes, an 
aggregated segment record is created to represent this io 
aggregation of road segments. In emkxxiiments of geo- 
graphic databases in which the data are organized by 
type, the aggregated segment data records may be 
included among the routing data 136 as shown in Figure 
5. In embodiments of the geographic database in which is 
the data are layered, the aggregated segment data 
records are found in layers above layer 0 (e.g.. layer > 0) 
as shown in Rgure 6. In embodiments of geographic 
databases in which the data are spatially organized, 
aggregated segment data records may be included so 
among the spatially organized data, such as in parcels 
220 of the data shown in Figure 8. 
[0058] Figure 1 1 shows aggregated segment data 
records 422 stored in a parcel 220(7} of routing data 
1 36. The parcel 220(7) is in a layer greater than layer 0. 25 
Wrth respect to Figure 11, ttie Illustrated parcel 220(7) 
represents only one of a plurality of parcels within the 
layer > 0. Furthermore, it is understood that there may 
be one or more layers greater than layer 0, each witii a 
plurality of parcels, each including aggregated segment 3o 
records. In a present embodiment, there are tiiree lay- 
ers greater than layer 0 (i.e., layers 1, 2 and 3) that 
include the arrangement of aggregated segment 
records illustrated in Figure 11. In alternative embodi- 
ments, there may be more or fewer than three layers. 35 

f The aggregated segment entity. 

[0059] In one embodiment, the aggregated segment 
entity a record 422 includes ail the same kinds of 4o 
attribute information that is included in non-aggregated 
road segment records (such as the road segment 
records 322 illustrated in Figure 9). Alternatively, tiie 
aggregated segment record 422 may include fewer of 
* the kinds of attribute information that are included in 45 
non-aggregated road segment records 322. In one 
embodiment, each aggregated segment record 422 
includes attribute information that corresponds to tiiose 
features tiiat adjacent road segments are required by 
the applicable criteria to have in common in order to so 
form tiie aggregated segment record. The attributes 
that adjacent segments are not required to have in com- 
mon may be either combined or dropped in the process 
of generating a single set of aggregated attributes for 
the aggregated segment record 422. ss 
[0060] The components of an aggregated segment 
record 422 are shown in Figure 12. The aggregated 
segment record 422 includes a segment identifier (e.g., 



"IDT 423 that identifies it as an aggregated segment. 
The aggregated segment record 422 includes data that 
identifies its end nodes 424 and 425 which correspond 
to the aggregated-segment-signrficant nodes. (For 
example, referring to Figure 10D, it is noted tiiat tiie 
aggregated segment AG12 includes nodes N102 and 
N1 12 that correspond to tiie end points of tiie aggre- 
gated segment) The aggregated segment record 422 
may also store information about the aggregated seg- 
ment that it represents including its lengtii 430. its aver- 
age speed 432. and a transit time 434. The aggregated 
segment record 422 may also store additional informa- 
tion 436. 

[0061 ] In a present embodiment, tiie aggregated seg- 
ment record 422 includes data tiiat can be used to iden- 
tify the segment records and node records tiiat 
represent tiie road segments and nodes between tiie 
road segments tiiat in aggregation are represented by 
tiie aggregated segment record. The aggregated seg- 
ment record 422 includes at least one pointer 426 to an 
an^ay 520 that includes abbreviated segment records 
522 and abbreviated node records 523. In a present 
embodiment, the abbreviated records are stored 
sequentially in the array 520, tiiat is, in order from one 
end (e.g., tiie left) of tiie aggregation to tiie other. In one 
embodiment, the pointer 426 refers to the first record in 
tiie array 520. In tiie embodiment shown in Rgure 12, 
the first record in the array 520 Is a abbreviated seg- 
ment record. The aggregated segment record 422 may 
also contains data 435 tiiat indicates a count of tiie 
number of abbreviated segment records in ttie con-e- 
spondlng array 520 of abbreviated segment and node 
records. Thus, these abbreviated records 522 and ^3 
are accessible tiirough the aggregated segment record 
tiirough tiie pointer 426 to tiie first abbreviated record 
and tiie count 435. 

g. Abbreviated 9^ments &nd s^l^r^vmt^tf node 
records. 

[0062] In a present embodiment, when an aggregated 
segment record is formed, abbreviated data records are 
formed tiiat represent the segments and nodes internal 
to ttie aggregated segment. Refering to Figures 1 1 and 
12, tiiese abbreviated data records include abbreviated 
segment records 522 and abbreviated node records 
523. The abbreviated segment records 522 and abbre- 
viated node records 523 are associated witii the aggre- 
gated segment record 422 and represent the nodes and 
segments that are represented in aggregation by tiie 
aggregated segment data record 422. These abbrevi- 
ated records 522 and 523 are maintained in tiie geo- 
graphic database in addition to ttie non-abbreviated 
segment records 322 that refer to ttie same road seg- 
ment features and tiie non-abbreviated node records 
323 ttiat refer to ttie same node features. 
[0063] In a present embodiment, ttiese abbreviated 
records 522 and 523 are maintained relatively dose 
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(physically and/or logically) to the aggregated segment 
record 422 that refers to them. This enables the aggre- 
gated segment record to have relatively quick access to 
the information contained in the abbreviated segment 
records 522 and abbreviated node records 523. In one 
embodiment, the abbreviated records 522 and 523 are 
included in the same layer of data as the aggregated 
segment record that refers to them. Further, in a present 
embodiment, in layers above layer 0 but below the high- 
est layer n, the abbreviated segment records 522 and 
abbreviated node records 523 are included in the same 
parcel as the aggregated segment record 422 that 
refers to them. This arrangement is illustrated in Figure 
11 wherein the abbreviated segments 522 and the 
abbreviated nodes 523 are included In the same parcel 
220(7) as the aggregated segment 422 that refers to 
them. Within each of the parcels atx}ve layer 0, such as 
the parcel 220(7). there may be a plurality of aggregated 
segment records 422, each of which refers to a plurality 
of abbreviated segment records 522 and abbreviated 
node records 523. 

[0064] When the abbreviated segments 522 and 
abbreviated nodes 523 are included in the same parcel 
of data as the aggregated segment record 422 that 
refers to them, the reference 426 in the aggregated seg- 
ment record 422 indicates the address or location of the 
abbreviated segments 522 and abbreviated nodes 523 
within the parcel. This reference or pointer 426 may be 
in the form of an offset from a starting position of the 
parcel to the abbreviated segment and node records. 
Alternatively, any other suitable means of reference may 
be used. 

[0065] Referring to Figure 12, as mentioned above, in 
one embodiment, the abbreviated segment and node 
records are stored in the array 520. Within the array 520 
the abbreviated segment and node records alternate. 
The first record in the array pointed to by the aggregated 
segment record is an abbreviated segment record 522. 
followed by an abbreviated node record 523. followed by 
an abbreviated segment record 522, and so on, alter- 
nating until the last two records in the list are reached, 
which are an abbreviated node record 523 followed by 
an abbreviated segment record 522. This alternating 
arrangement of abbreviated segment and node recads 
con-esponds to the alternating arrangement of the phys- 
ical nodes and road segments that are represented in 
aggregation by the aggregated segment record. The 
first abbreviated segment record 522 in the array repre- 
sents the first segment encountered from an endpoint of 
an aggregated segment when traversing the aggrega- 
tion represented t>y the aggregated segment record 
from an endpoint thereof. The next abbreviated record 
encounter is the first of the one or more internal nodes 
of the aggregated segment, starting from the same end- 
point of the aggregated segment These abbreviated 
records alternate until the abbreviated segment immedi- 
ately preceding the other endpoint of the aggregated 
segment is encountered. 



[0066] Referring to Rgure 13, each abbreviated seg- 
ment record 522 contains a segment identifier 543 and 
data that indicate a length 544 and a transit time 545. In 
a present embodiment, the length 544 and a trar^it time 

5 545 of the abbreviated segment 522 are stored as a sin- 
gle fraction of the length 430 and transit time 434 of the 
aggregated segment record 422 that refers to them. 
The abbreviated segment record 522 may also contain 
additional informaton 548 by which the full (i.e., non- 

10 abbreviated) version of the segment record (e.g. , a seg- 
ment record 322) can be found. In one embodiment, this 
information 548 is a data flag which can be used as a 
reference to a layer 0 parcel klentification. as explained 
below. The abbreviated segment record 522 may also 

/5 contain additional information 549, such as the bearing 
of the road segment represented by the abbreviated 
segment, although such Information may be accessed 
from the referenced layer 0 data record 322 instead. 
[0067] Refenring to Figure 14, each abbreviated node 

20 record 523 contains an abbreviated node identifier 
("ID") 553 and data that identifies its position 554. The 
abbreviated node recad 523 may also contain addi- 
tional information, such as a pointer or reference 559. 
by which the full (i.e., non-abbreviated) version of the 

25 node record 323 can he found. The abbreviated node 
record 523 may also contain additional information 555. 
[0068] As mentioned above, the abbreviated segment 
and node records include references to the non-abbre- 
viated versions of these records. These references may 

30 be used to obtain information that is unavailable in the 
abbreviated segment and node data records, but is 
included in the non-abbreviated versions of these 
records. For example, the non-abbreviated versions of 
these records are used when the calculated route is 

35 complete and cross-references to the other data types, 
such as the map display type and the maneuver type, 
are required. In the abbreviated segment record 522. 
the reference 548 is a data flag that indicates whether 
the abbreviated segment record 522 contains a parcel 

40 ID index. (The reference 559 in the abbreviated node 
record 523 may include a similar data flag.) If an abbre- 
viated segment or node record contains a parcel ID 
index field, then that abbreviated segment or node 
record has that parcel ID at layer 0. IHowever, if an 

45 abbreviated segment or node record does not contain a 
parcel ID index, then the node is assumed to have the 
layer 0 parcel ID of the preceding abbreviated node (or 
segment) record that did contain a parcel ID field. In this 
way, if the layer 0 entities referenced by successive 

50 abbreviated records are located in the same parcel, the 
parcel ID number is not reiquired to be repeated for each 
successive abbreviated record. 

h. Upward Referencing 

55 

[0069] In a present embodiment each of the segment 
records 322 in layers less than layer n includes data that 
identifies each of the aggregated segment records 422 
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in each of the higher layers that represent an aggrega- 
tion of road segments that includes the road segment 
represented by the segment record 322. A diagram 
illustrating this feature of the segment data record 322 is 
included in Figure 15. As shown in Figure 15. in addition 5 
to the other types of attrbutes included in the segment 
data record 322, there is a reference 648 to each of the 
aggregated segment records 422 in higher layers that 
represents aggregations of road segments that include 
the road segment represented by the segment record. 10 
In a present embodiment, the reference 648 in the seg- 
ment record 322 identifies the aggregated segment 
records by aggregated segment ID 423 (in Figure 12) 
and layer (i.e.. 1 through n) in which the aggregated 
segment record appears. This inforration is in addition 15 
to the other information included in the segment data 
record 322. 

IV. EMBODIMENTS WITH INTERLEAVING OF DATA 
TYPES 20 

a. Separation of aggregate d and abbreviated records 

[0070] In a present embodiment for some layers of 
routing data above layer 0, the abbreviated segment 25 
records 522 and abbreviated node records 523 are 
stored in the same parcel as the aggregated segment 
record 422 that refers to them, as described above. 
However, according to a present embodiment, in at 
least one layer of routing data above layer 0, the abbre- so 
viated segment records and abbreviated node records 
are stored in a separate parcel from the parcel that con- 
tains the aggregated segment record that refers to 
them. Specifically, in one present embodiment, for the 
highest layer (i.e.. layer n. where n=4}. the abbreviated 35 
segment and abbreviated node records are stored in a 
separate parcel from the parcel that contains the aggre- 
gated segment record that refers to them. This latter 
arrangement is shown in Figure 16. As shown in Figure 
16, the abbreviated segment records 522 and abbrevi- 40 
ated node records 523 are stored in a parcel 220(3) that 
is separate from the parcels 220(1), 220(2) . . that con- 
tain the aggregated segment records 422 that refer to 
them. In a present embodiment this parcel 220(3) of 
abbreviated records contains abbreviated segment 45 
records 522 and abbreviated node records 523 (and 
possibly some additional information, such as header 
information). However, the parcel 220(3) containing the 
abbreviated records does not include any routing data. 
As illustrated in Figure 16, the abbreviated records 522 so 
and 523 are included in the same layer (i.e., layer n) as 
the aggregated segment records 422 that refer to them. 
In an alternate embodiment, the parcel 220(3) of abbre- 
viated segment records 522 and abbreviated node 
records 523 may be located in another layer or else- ss 
where in the database. 

[0071 ] As with the aggregated segment records that 
are included in the layers below layer n, each aggre- 



gated segment record Includes a pointer or other suita- 
ble reference to the abbreviated segment and node 
records that represent the features represented in 
aggregation by the aggregated segment record. Figure 
17 illustrates the components of an aggregated s^- 
ment record and its referenced abbreviated segment 
and node records according to the embodiment shown 
in Figure 16. The aggregated segment record 422 
includes at least one pointer 426 to an array 520 that 
includes abbreviated segment records 522 and abbrevi- 
ated node records 523. In this embodiment, the pointer 
426 refers to the first record in the array 520. Because 
the abbreviated records are stored in a separate parcel 
from the aggregated segment records that refer to 
them, the reference 426 in an aggregated segment 
record 422 to its associated abbreviated segment and 
node records 522, 523, includes an appropriate Identifi- 
cation of the parcel in which the abbreviated records are 
located. As in the array 520 described in connection 
with Figure 12, the abbreviated records are stored 
sequentially in the array 520 in order from one end of 
the represented aggregation to the other. However, 
unlike the embodiment shown in Figure 12, when the 
abbreviated records are in a separate parcel from the 
parcel that contains the aggregated segment record 
that refers to them, the first record in the array 520 is an 
abbreviated node record 523. followed by an abbrevi- 
ated segment record 522, and so on. alternating until 
the last two records in the list are reached, which are an 
abbreviated segment record 522 followed by an abbre- 
viated node record 523. When tiie abbreviated records 
are in a separate parcel from the parcel that contains 
the aggregated segment record tiiat refers to them, the 
first record in the an^ay 520 Is an abbreviated node 
record 523 which represents one of the end points of 
tiie referencing aggregated segment record and the last 
record in the an^ay 520 is an abbreviated node record 
523 which represents the other end point of the refer- 
encing aggregated segment record. It is useful to have 
these aggregated node records 523 that represent the 
aggregated segment end points in the array 520 when 
the abbreviated records are located in a separate parcel 
from the aggregated segment record 422 that refers to 
them because othenvise tiiere may not be records in 
the parcel containing the abbreviated records that rep- 
resent these end points of the aggregated segment. In 
otiier respects, the aggregated segment records 422 
and abbreviated records 522, 523, in layer n are similar 
to those in the previously described embodiment. 
[0072] The abbreviated segment records 522 and the 
abbreviated node records 523 in the layer n parcel 
220(3) include appropriate references to corresponding 
non-abbreviated segment and node records contained 
in the parcels 220(4) and 220(5) in layer 0 that represent 
the same con'esponding geographic features. As 
described in connection with the previous embodiment, 
if the information included in the non-abbreviated seg- 
ment or node records is needed for a navigation func- 
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tion, the references included in the al3breviated 
segment and node records contained in the layer n 
abbreviated record parcel 220(3) can he used to find the 
con-esponding non-abbreviated segment and node 
records in the layer 0 parcels 220(4) and 220(5) (illus- 5 
trated in Figure 16). 

[0073] Separating the abbreviated segment and 
abbreviated node records from the aggregated segment 
record that refers to them has the effect of allowing the 
routing parcels that contain the aggregated segment 10 
records to hold more routing data other than the abbre- 
viated segment and node record data. This allows the 
parcels of routing data that contain the aggregated seg- 
ment reoorcte to represent geographic features that are 
encompassed within larger sized rectangular areas, is 
Therefore, fewer such, parcels of routing data are 
needed when calculating a route across the geographic 
area thereby generally enhancing navigation system 
performance for some types of functions such as route 
calculation. 20 
[0074] (According to this alternative embodiment, the 
abbreviated records are separated from the aggregated 
records that refer to them only in the highest layer (i.e.. 
layer n, where n=4) of data. In another version of this 
alternative embodiment, the abbreviated records may 25 
he separated from the aggregated records in other lay- 
ers as well. According to still another version of this 
alternative embodiment, the abbreviated records may 
be separated from the aggregated records that refer to 
them in all the layers of data in which aggregated 30 
records are present.) 

b. Kinds of Interleaving 

[0075] As previously mentioned, storing the abbrevi- 35 
ated records separately from the routing data that 
Includes the aggregated segment records that refer to 
them can provide certain advantages that enhance nav- 
igation system performance. Further advantages can 
be obtained In an embodiment wherein the routing data 40 
(that include the aggregated segment data records) are 
interleaved with the abbreviated records. This may 
reduce the search and access times for data when per- 
forming certain kinds of navigation functions and 
thereby possibly further enhance navigation system 45 
performance. Specifically, in this further alternative 
embodiment, the parcels that contain the routing data 
that Include aggregated segment data records are inter- 
leaved witii the parcels tiiat contain the abbreviated 
records that are referenced by the aggregated segment so 
records within tiie same layer. 
[0076] Rgures 18, 19, and 20 show three different 
ways that parcels containing routing data (including 
aggregated segment records) and parcels that contain 
abbreviated record data (which are referenced by the ss 
aggregated segment records) can be arranged within a 
layer. For purposes of this embodiment the interleaving 
of abbreviated record data with routing data within a 



layer is described. The advantages that result from 
interleaving different data types, and In particular par- 
cels of different data types, are not limited to just routing 
data and abbreviated record data. It is understood ttiat 
tiie disclosed concepts can be extended to otiier types 
and layers of data as well, as described below. There- 
fore, various navigation functions can benefit from tiie 
performance enhancements associated with interleav- 
ing data types. 

[0077] Figure 18 shows a plurality of parcels 220 
witiiin a layer n of routing data. These parcels Include 
parcels that include routing data (labeled with an "R") 
and parcels ttiat include abbreviated segment and node 
records (labeled with an "A"). The routing parcels con- 
tain aggregated segment records ttiat include refer- 
ences to tiie abbreviated segment and node records 
ttiat represent, individually, tiie road segments and end- 
points thereof that the aggregated segment records rep- 
resent In aggregation. In the embodiment shown in 
Figure 18, even ttiough all the parcels that contain 
abbreviated segment and node records are located in 
ttie same layer of routing data as tiie routing parcels that 
include the aggregated segment records ttiat refer to 
ttiem, all tiie parcels tiiat contain the abbreviated seg- 
ment and node records are located and stored apart 
from (I.e., before or after) ail the parcels that contain ttie 
layer n routing parcels that include ttie aggregated seg- 
ment records that refer to tiiem. As mentioned above, 
placing the parcels that contain tiie abbreviated seg- 
ment and node records in the same layer as the parcels 
that contain ttie aggregated segment records that refer 
to ttiem affords the advantage that generally less time is 
required to access the abbreviated records when they 
are referenced by ttie aggregated segment records, 
ttiereby leading to improved navigation system perform- 
ance. 

[0078] Alttiough tiie embodiment shown in Figure 18 
provides potential performance advantages, still further 
advantages can be obtained If ttie parcels containing 
tiie abbreviated segment records are placed even 
closer to tiie parcels containing ttie aggregated seg- 
ment records tiiat refer to ttiem. The embodiment 
shown in Figure 19 shows an anrangement of parcels 
ttiat affords this advantage. In ttie embodiment of Figure 
19. following each parcel of routing data is a parcel con- 
taining abbreviated records. The abbreviated records in 
each parcel of abbreviated records are referenced by 
ttie aggregated segment records in the immediately 
adjacent parcel. (In Figure 19. tiie parcel containing the 
abbreviated segment and node records is shown imme- 
diately following the parcel that contains the routing 
data records ttiat include ttie aggregated segment 
records ttiat refer to them. In an alternative embodi- 
ment, the parcel containing the abbreviated segment 
and node records can immediately precede the parcel 
ttiat contains tiie routing data records ttiat include ttie 
aggregated segment records that refer to them.) 
[0079] The arrangement shown in Figure 19 may 
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afford even further advantages over the embodiment 
shown in Rgure 18 for certain functions. Because the 
parcel containing the abbreviated segment and node 
records is immediately adjacent to the parcel containing 
the routing data that includes the aggregated segment s 
records that refer to them, even less time may be 
required to access the abbreviated records when they 
are referenced by the aggregated segment records, 
thereby leading to even further inproved navigation 
system performance. w 
[0080] A disadvantage associated with the arrange- 
ment shown in Figure 19 is that the amount of data 
associated with the abbreviated segment and node 
records referenced by the aggregated segment records 
in a single parcel of routing data does not necessarily is 
conform to an ideal parcel size. If the routing parcel con* 
tains relatively few aggregated segment records or 
aggregated segment records that represent aggrega- 
tions of relatively few segments, there will he a corre- 
spondingly few abbreviated records in the adjacent so 
parcel of abbreviated records. Similarly rf the routing 
parcel contains relatively many aggregated segment 
records or aggregated segment records that represent 
aggregations of relatively many segments, there will be 
a correspondingly many abbreviated records in the 25 
adjacent panel of abbreviated records. In the embodi- 
ment of Figure 19. the data size requirement for the 
abbreviated segment and node records referenced by 
the aggregated segment records in each single parcel 
of routing data depends upon the number and kind of 30 
aggregated segment records in the parcel of routing 
data. In turn, the number and kind of aggregated seg- 
ment records in a parcel of routing data depends, at 
least to some extent, on the represented road network. 
Since road networks can be relatively variable, the data 35 
size requirements for the abbreviated segment and 
node records referenced by the aggregated segment 
records in a single parcel of routing data can also vary 
considerably. 

[0081 ] In general, the abbreviated segment and node 40 
records referenced by the aggregated segment records 
in a parcel require less the and sometimes considerably 
less than, an ideal parcel size. This mear^ that in the 
embodiment shown in Figure 19, substantial padding 
may be required to be added the abbreviated record 45 
data in some parcels of abbreviated records to maintain 
a uniform parcel size among the parcels within the layer. 
This has the result tiiat the parcels that contain the 
abbreviated records may be less than a desired fill per- 
centage If a desired parcel fill percentage is 80%. some so 
of the parcels that contain abbreviated segment and 
node records may be less than 50% or even less than 
20% full. It is generally undesirable to have parcels sub- 
stantially less than full. One reason that less than full 
parcels is undesirable is that data storage space is ss 
wasted that could othenwise be used to store informa- 
tion that can he valuable to the end-user. Another unde- 
sirable effect of having parcels that are substantially 



less than full is increased fragmentation of the data- 
base. This can result in increased search and access 
times leading to poor performance. 
[0082] Another potential disadvantage of the embodi- 
ment of Figure 19 is that under some circumstances, 
the data requirements for tiie abbreviated segment and 
node records referenced by the aggregated segment 
records in a single parcel of routing data may exceed 
the maximum parcel siza 

[0083] With respect to the errisodiment in Figure 1 9, it 
is possible to make the parcels containing abbreviated 
segment and node records smaller (or larger} in size 
than the immediately adjacent parcels that contain the 
routing data that include the aggregated segment 
records that to refer to them. However, making tiie par- 
cels containing the abtxeviated segment and node 
records different sizes tiian the parcels containing the 
routing data does not reduce fragmentation. Further- 
more, since tiie factors used to determine a desired par- 
cel size may include specific characteristics of the 
media upon which the data are stored, there are rela- 
tively few, available preferred sizes in which a parcel can 
be provided in order to obtain tiie desired performance 
characteristics. 

[0084] Thus, attiiough the interleaving arrangement 
shown in Figure 19 nfiay provide performance advan- 
tages in navigation systems for some data types, it may 
not be suitable for other data types. With respect to the 
embodiment of interleaved data types shown in Figure 
19, it is best suited for types of data in which the parcel 
sizes of the different data types can be balanced readily 
[0085] Rgure 20 shows another arrangement for inter- 
leaving parcels of abbreviated segment and node 
records with parcels containing routing data tiiat include 
the aggregated records that reference abbreviated seg- 
ment and node records. In Figure 20. the parcels that 
contain abbreviated segment and node records are 
formed to have a size that conforms to a desired parcel 
size and are formed to have a generally high fill percent- 
age. In one embodiment, the parcels containing abbre- 
viated segment and node records may have the same 
size as the routing data parcels that contain the aggre- 
gated segment records tiiat refer to tiiem. For example, 
if the routing data parcels are provided in a 16 K size, 
the parcels containing tiie abbreviated segment and 
node records may also be provided In sizes of 16 K 
each. Other sizes are suitable. 
[0086] In Figure 20. tiie parcels containing routing 
data are interleaved witii tiie parcels containing the 
abbreviated segment and node recorda In a present 
embodiment, each parcel ttiat contains abbreviated 
segment and node records is grouped togetiier with ttie 
one or more routing parcels that contain tiie aggregated 
segment records tiiat refer to tiiem. In one embodiment, 
ttie parcel tiiat contains tiie abbreviated segment and 
node records tiiat are referenced by aggregated seg- 
ment records contained in one or more routing parcels 
are located immediately after these routing parcels. In 
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an alternative embodiment, the parcel that contains the 
abbreviated segment and node records that are refer- 
enced by aggregated segment records contained in one 
or more routing parcels may be located immediately 
before these routing parcels, in a preferred embodi- $ 
ment, the placement of the parcel that contains the 
abbreviated records dep^s upon the spatial organiza- 
tion of the data within the layer, as described further 
below. 

[0087] Referring to Rgure 20, four layer n parcels con- io 
taining routing data are followed by one parcel contain- 
ing abbreviated segment and node records, The one 
parcel containing abbreviated segment and node 
records contains all the abbreviated segment and node 
records referenced by all the aggregated segment is 
records contained in the four routing data parcels that 
immediately precede it. In Figure 20. following the first 
abbreviated record parcel are two more routing parcels 
followed by another parcel containing abbreviated 
records. This second parcel of abbreviated records con- 20 
tains the abbreviated records referenced by the aggre- 
gated segment records contained In the two routing 
parcels Immediately preceding it. In the embodiment 
shown in Rgure 20, the number of parcels of routing 
data and the number of parcels of abbreviated recads 25 
are determined in order to (1) maintain a desired parcel 
size and fill percentage among the parcels in the layer, 
and (2) maintain the spatially parcelized routing parcels 
close to the spatially parcelized abbreviated recad par- 
cels that represent the same geographic features. The 30 
embodiment shown in Rgure 20 combines the advan- 
tage that the abbreviated segment and node records 
are stored relatively close to the aggregated segment 
records that refer to them with the advantage that all the 
parcels conform generally to a desired parcel size and 3s 
fill percentage. 

c. Process for forming interleaved data 

[0088] As noted above, in a preferred embodiment the 40 
routing parcels are spatially parcelized, and likewise the 
parcels containing the abbreviated segment and node 
records are spatially parcelized. In a prefen^ed embodi- 
ment, the parcels containing the abbreviated segment 
and node records are parcelized in parallel with the 45 
routing data parcels with which they are interleaved. A 
process for forming the interleaving arrangement is 
described below. 

[0089] Processes for forming a geographic database 
including layered parcelized routing data are disclosed so 
in Ser. Nos. 08/924,328, 08/935,809, and 08/740,295, 
the entire disclosures of which are incorporated by ref- 
erence herein. Briefly, one process for forming a layered 
parcelized geographic database having at least one 
interleaved portion is Illustrated in Rgure 21. (In Rgure ss 
21 , the general Steps of the process are shown on the 
left and tiie conresponding component parts used in the 
Steps are shown on the right.) 



[0090] Starting with a geographic database 900 that is 
provided in a generalized data format, separate inter- 
mediate format files 902 for each data type and layer 
are formed (at Step A). The generalized data format 
geographic database 900 may be in a proprietary for- 
mat or in a non-proprietary format. In the generalized 
data format geographic database file 900, the geo- 
graphic data may be undifferentiated as to type and 
layer. These intermediate format files 902 formed from 
tiie generalized data format database file 900 are cre- 
ated in order to derive each of tiie different types of 
data, such as routing, cartographic, point-of-interest 
maneuver, and so on, as shown in Figure 5, as well as 
to derive each of the layers of some of tiiese types, as 
shown in Rgure 6. 

[0091 ] After each of tiiese separate intermediate for- 
mat files 902 is created, each of tiiese intermediate for- 
mat files 902 is parcelized to form parcels 906 of data 
records of each data type for each layer (at Step B). Dif- 
ferent kinds of parcelization processes can be used, 
including different kinds of processes for spatial parceli- 
zation. as described above. As the parcels 906 for each 
of tiie separate types and layers are formed, tiie parcels 
906 for each layer and type are concatenated into a sin- 
gle file 910 (at Step C). With respect to a portion of tiie 
concatenated file 910 In which parcels are interleaved, 
tiie parcels from the two or more parcelized intermedi- 
ate files 906 are selected and interieaved (at Step D), as 
descnlsed in more detail below. ' 
[0092] As tiie separate parcels 906 for each of tiie 
separate types and layers are formed parcel identifica- 
tions are assigned. After all the separate parcels 906 for 
each of the separate types and layers are concatenated 
into a single file 910 and parcel identifications are 
assigned, parcel references tiiroughout all the data 
records and indices are updated to reflect tiie new 
assigned parcel identifications to form a final famat file 
912 (at Step E). 

[0093] These general steps for forming a geographic 
database represent only one way that a geographic 
datat)ase can be formed and it is understood that tiiere 
are otiier methods for forming a geographic database 
tiiat incaporates the interleaving of different types of 
data. A more detailed description of aspects of tiie proc* 
ess for fonning a geographic database having an inter- 
leaved portion Is described as follows: 
[0094] According to one embodiment, to form a geo- 
graphic database that interleaves different types of 
data, a separate intermediate file is formed for each of 
tiie different types of data tiiat are to be interleaved. For 
example, in order to form a geographic database that 
includes parcels tiiat contain routing data including 
aggregated segment records and separate parcels that 
contain abbreviated segment and node records refer- 
enced by the aggregated segment records (as shown in 
Figures 17-20), separate intermediate format files are 
formed for the routing data and tor the abbreviated seg- 
ment and node data. The separate intermediate format 
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file for the abbreviated records contains the portions of 
the generalized data format geographic database file 
that are necessary to derive the abbreviated segment 
and node records (such as the records 522 and 523 In 
Figures 13 and 14, respectively). $ 
[0095] If parcels containing abbreviated records are to 
be interleaved with parcels that contain routing data in 
more than one layer, separate intennediate format files 
of abbreviated segment and node records are formed 
for each s^>arate layer In a present embodiment, the io 
abbreviated segment and node records are stored in 
separate parcels fron the aggregated segment and 
node records that refer to them only in the highest layer 
(i.e., layer n, where n=4) of the routing data. However, in 
altemative embodiments, abbreviated segment and is 
node records may be stored In separate parcels from 
the aggregated segment and node records that refer to 
them in any layer that contains aggregated segment 
records. 

[0096] In addrtion, in further alternative entKxIlments. 20 
if parcels of data types other than routing data and 
abbreviated records are to be interleaved, Intermediate 
format files of these different data types are formed, as 
necessary 

[0097] Once the intermediate format files for each 25 
l^er of routing data and each layer of abbreviated seg* 
ment and node records are formed, each of these Inter- 
mediate format files is parcelized. In a prefen-ed 
embodiment, routing data layer 0 is parcelized first 
Alternatively another of the types of data, such as the so 
cartographic data or the maneuver data, may be 
parcelized first. In parcelizing the routing layer 0 data, 
any suitable parcelization method can be used, such as 
any of the parcelization methods disclosed in Ser. Nos. 
08/924.328. 08/935.809. and 08^40.295. the entire dis- 35 
closures of which are incorporated by reference herein. 
[0098] After the routing layer 0 data are parcelized, the 
higher layers of routing data are parcelized. In a pre- 
ferred embodiment, the higher layers of routing data are 
parcelized in parallel with the parcelization method used 40 
for routing layer 0 data. This means that when forming 
parcels for a higher layer of routing data, the same 
boundaries that were defined in the process of deter- 
mining the rectangular areas associated with the routing 
layer 0 parcels are used to define the rectangular areas 45 
associated with each higher layer parcel. Of course, 
since higher layers of data include fewer records, higher 
layer parcels may be assodated with larger rectangular 
areas. However, if any higher layer parcel is associated 
with a larger rectangular area than a lower layer parcel, so 
the larger rectangular area assodated with a higher 
layer parcel will exactly encompass the smaller rectan- 
gular areas associated with two or more lower layer 
routing data parcels. 

[0099] After the intermediate format file representing ss 
a layer of routing data having aggregated segments is 
parcelized, the intermediate fbrmat data file containing 
the abbreviated segment and node records for the same 



layer is parcelized. (Note that the intermediate data file 
containing the abbreviated segment and node records 
can be parcelized immediately after the layer of routing 
data are parcelized, or alternatively, the intermediate 
data file containing the abbreviated segment and node 
records can he parcelized after other types or layers of 
data are parcelized.) In a preferred emtKxliment, the 
intermediate data file containing the abbreviated seg- 
ment and node records is parcelized in parallel with the 
routing data. The parallel parcelization of an intermedi- 
ate format file containing abbreviated segment and 
node records is similar to the parallel parcelization of 
intermediate format files of higher layers of routing data, 
as described above. Thus, the same boundaries that 
were defined for the rectangular areas assodated with 
the routing layer 0 parcels are used, to the extents nec- 
essary, to define rectangular areas associated with par- 
cels of the abbreviated segment and node records. 
Thus, a rectangular area associated with a parcel of 
abbreviated segmerrt and node records either corre- 
sponds exactly to the rectangular area associated with 
the routing data parcel that indudes the aggregated 
segment records that will refer to the abbreviated seg- 
ment and node records or corresponds exactly to two or 
more rectangular areas associated with the two or more 
routing data parcels that include the aggregated seg- 
ment records that refer to the abbreviated segment and 
node records. This arrangement is illustrated graphi- 
cally in Figure 22. (In the event that the abbreviated 
records referenced by the aggregated segment records 
in a parcel of routing data comprise a substantially 
larger amount of data than the routing parcel, the oppo- 
site relationship will apply, i.e.. the rectangular areas 
associated with two or more abbreviated records par- 
cels will exactiy encompass the rectangular areas asso- 
dated with a single routing parcel.) 
iPlOO] Rgure 22 shows a map 612 of a portion of a 
geographic region. The region is overlaid with a plurality 
of boundary lines. These boundary lines are selected 
according to a parcelization method in order to deter- 
mine a plurality of rectangular areas. As mentioned 
above, any suitable parcelization meUiod may be used. 
The boundaries forming each of^the rectangular areas 
are selected so that each rectangular area encom- 
passes geographic features that are represented by 
geographic data records contained witiiin a separate 
parcel for a given layer and type of data. In Rgure 22, 
the boundaries define the rectangular areas that 
encompass geographic features represented by routing 
data records contained in separate parcels of routing 
layer 0 data (It is understood that Rgure 22 shows just 
a portion of a geographic region. In a geographic region 
represented by a geographic database, such as the 
geographic database 40 used witii a navigation system 
1 0 in Rgure 1 . there may be hundreds of such rectangu- 
lar areas, each associated with a separate parcel of 
routing layer 0 data.) 

[01 01 ] When forming parcels of abbreviated segment 
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and node records, the boundary lines previously 
defined for the routing layer 0 data are used to define 
the rectangular areas thai encompass the abbreviated 
segment and node records to be contained in each par- 
cel. In a present embodiment, these abbreviated seg- s 
ment and node records have relatively smaller data size 
requirements than the routing data for a conresponding 
area. Therefore, parcels formed of abbreviated segment 
and node records may represent larger rectangular 
sized areas. However, since the boundary lines to be io 
used when defining a rectangular area associated with 
a parcel are constrained to those previously defined for 
routing layer 0 data, a rectangular area associated with 
a parcel of abbreviated segment and node records 
includes entire rectangular areas associated with rout- 15 
ing layer parcels For example, in Rgure 22. if the 
abbreviated segment and node records that represent 
the features contained in the four rectangular areas 
650(1), 650(2). 650(3), and 650(4) are less than a max- 
imum parcel size, a parcel of all these abbreviated seg- 20 
ment and node records can be formed. Similarly, if the 
abbreviated segment and node records that represent 
the features contained in the two rectangular areas 
650(5) and 650(6) are less than a maximum parcel size, 
a parcel can he formed of these abbreviated segment 25 
and node records. 

[01 02] After parcelization, the intermediate format file 
contains the parcelized abbreviated segment and node 
records In a plurality of parcels. Each parcel is padded 
to a desired size. The parcels are arranged in an order 30 
that reflects the spatial organization of the data. 
[0103] Once the intermediate format file containing 
the routing data for layer n is parcelized and the inter- 
mediate format file containing the abbreviated segment 
and node data for layer n is parcelized. the parcels of 3S 
the two intermediate format files of different data types 
can be interleaved. The intermediate format files to be 
interleaved are identified to a compiler or other process 
that forms the final format geographic database file. The 
. identified files are input into the compiler or other pro- 40 
gram or process. (In a present embodiment the com- 
piler also receives as input the layers and types of data 
that are not going to be interleaved.) 
[0104] As illustrated in Figure 21 , in forming the final 
format geographic database file, the portion of the file 45 
that contains interleaved parcels of different data types 
may be included among other portions that include non- 
interleaved parcels, if any For example, the compiler 
may store the non-interleaved parcels of routing layer 
data 0» followed by the non-interleaved parcels of rout* so 
ing layer 1, and so on. When the compiler gets to an 
interleaved layer, (e.g., layer n routing data), both the 
parcelized intennediate format file containing routing 
layer n data and the parcelized intermediate format file 
containing the layer 4 abbreviated records are present, ss 
In forming the final format geographic database file, the 
spatial organization of the routing data and abbreviated 
record data in ttie interleaved layer is maintained. To 



facilitate maintaining the spatial organization of the 
data, a kd-tree is used during the interleaving process. 
Rgure 23 shows a kd-tree representing the parcels 
formed of the data encompassed within the rectangular 
areas of Figure 22. In a preferred embodiment, a kd- 
tree is formed during the parcelizatfon of the routing 
layer 0 data. An entry or node in the kd-tree is associ- 
ated with each "cut" (i e.. division) of an encompassing 
rectangular area which is made when forming the indi- 
vidual smaller rectangular areas associated with each 
of the parcels of routing layer 0 data. Each leaf node 
(i.e., a node with no children nodes) of the kd-tree rep- 
resents one of the routing layer 0 parcels. Therefore, a 
layer 0 parcel can be found using this kd-tree. (A form of 
the kd-tree can be stored as a file and used as search 
tool in finding data spatially within the parcels, as known 
to those of skill in the art.) Each parcel (such as a higher 
layer parcel or a parcel of abbreviated records) which is 
formed without making all the cuts required for the layer 
0 parcels is represented by one of the internal nodes of 
the kd-tree. 

[01 05] The kd-tree formed when parcelizing the rout- 
ing layer 0 data can also be used when interleaving the 
parcels of routing data and the parcels of abbreviated 
record data (as illustrated at Step D in Figure 21). The 
rectangular areas associated with the parcels of layer 4 
routing data and parcels of abbreviated record data do 
not necessarily share the exact same boundaries (i e. 
in Rgure 22) as the rectangular areas associated with 
the parcels of layer 0 routing data that were used to form 
the kd-tree. Moreover, tiie rectangular areas associated 
witii the parcels of abbreviated records do not neces- 
sarily share the exact same boundaries as the rectan- 
gular areas associated with the parcels of routing layer 
4 data. However, the cuts used to form the layer 4 rout- 
ing parcel boundaries and the abbreviated record parcel 
boundaries are included in the kd-tree, since these cuts 
were made in the process of forming the routing layer 0 
parcels. Accordingly, when interleaving these different 
types of data, the kd-tree can be used to spatially organ- 
ize the parcels of these different types of data. The 
nodes of the kd-tree are traversed in order. As each 
node of the kd-tree is encountered in order, if a routing 
layer 4 parcel or an abbreviated record parcel was 
formed by the cut associated with the kd-tree node, the 
parcel (routing or abbreviated record or both) is added 
to tiie portion of the final format file corresponding to the 
routing layer 4 data By traversing the kd-tree in order, 
the routing layer 4 parcels and abbreviated record par- 
cels associated with the same geographic features can 
be identified and grouped together in the portion of the 
final format file corresponding to routing layer 4. In tiiis 
manner, since tiie abbreviated records represent the 
same geographic features as the aggregated segment 
records that refer to them, by using the represented 
geographic features the abbreviated segment records 
can be placed close to the aggregated segment records 
that refer to tiiem. 
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[01 06] After the routing data parcels and abbreviated 
records parcels are interleaved, they can be concate- 
nated with the parcels of other types and layers into the 
final format ffle. Parcel identification numbers are 
assigned and parcel references within each parcel are s 
updated, as necessary to fbnm the final fbnmat file 912 
(in Step E of Rgure 21). 

flf. Attemaiive interleaved embodiments 

10 

[01 07] For purposes of the above described embodi- 
ment, it was disclosed that parcels containing abbrevi- 
ated records can be Interleaved in the same layer as 
parcels containing other kinds of data, such as routing 
data including aggregated segment records. Interteav- is 
ing of different data types can be extended to other 
types of data. Any two kinds of spatially aganized data 
can be interleaved at any level in order to provide 
advantages for certain navigation functions. For exam- 
ple, cartographic data can be interleaved with point-of- 20 
interest data. Similarly, cartographic data can be Inter- 
leaved with routing data. Likewise, non-spatially organ- 
ized types of data can be interleaved with each other or 
with spatially organized types of data. 
[01 08] In another embodiment, index files for certain 25 
kinds of data types can be interleaved with the data type 
that is being indexed. 

[0109] In still further alternative embodiments, parcels 
of different types can be interleaved according to a cus- 
tom ordering. The custom ordering can be defined by 30 
an arbitrary function that specifies an explicit ordering 
pattern. During fonration of the final format fQe, the 
compiler receives instructions along with the identifica- 
tion of the two or more parcel types to be interleaved. 
The instructions specify the pattern and/or ordering for 35 
each parcel of each type. The compiler then implements 
this ordering when the parcels are interleaved Into the 
final format file. 

V. FURTHER ALTERNATIVE EMBODIMENTS 40 

[01 1 0] The embodiments described above represent 
only specific implementations of the inventive concepts 
disctosed herein. Various other implementations and 
alternative embodiments are considered to he encom- 45 
passed within the scope of the present disclosure. For 
example, in the disclosed embodiments, aggregated 
segment records are stored in higher layers that are 
physically distinct from the lowest layer (e.g., layer 0") 
of data, in one alternative ennbodlment. separate layers so 
of data may be provided wrthout physically storing sep- 
arate layers. Instead, the separate layers may be pro- 
vMed by suppressing certain ranks of the data during 
runtime of the navigation functions. Using suppression 
of ranks in this manner, some of all of the separate lay- 55 
ers may be combined and rank suppression may be 
used as needed to reduce the number of records to be 
examined instead of providing separate layers. 



[01 1 1 ] In other alternative embodiments, aggregated 
segments and aggi^egated segment records may be 
formed in different ways. In tiie disclosed embodiments, 
using a rank attribute that defines separate layers repre- 
sents one way by which aggregated segment records 
can be formed. However, In alternative embodiments, 
aggregated segment records may be formed without 
using rank attributes. For example, aggregated seg- 
ments may be formed by taking into account traffic pat- 
terns or vehicle usage. 

[01 12] In further alternative embodiments, the naviga- 
tion system should be understood to include any com- 
puter-based system that provides navigation functions 
to an end-user regardless of hardware platform or archi- 
tecture. For example, the navigation system may 
include any kind of portable system, including hand- 
held systems, systems Installed on personal digital 
assistants or notebook computers. In alternative 
embodiments, the navigation system may include navi- 
gation application software installed on a personal com- 
puter, such as a desktop computer Further, the 
navigation system may be implemented in various dif- 
ferent environments, including networked environments 
and client-server platform environments. The navigation 
applk^ation program and the geographic database need 
not be located in the same location, but may be con- 
nected over a network. The geographic database may 
be located remotely from the end-user and tiie data 
transmitted to the erKl-user over a wireless communica- 
tions link. 

[0113] In tiie ennbodlments described above, geo- 
graphic data were described as being parcelized. In 
alternative embodiments, tiie geographic data may not 
be parcelized or may be organized in a different man- 
ner. These data records may be either compressed or 
not compressed. 

[01 1 4] In the embodiments described above, certain 
terminology Is used to refer to components, data st'uc- 
tures, and so on. in the navigation system, application, 
and database. Ottier terminology may be used to refer 
to these kinds of entities and it Is understood that the 
subject matter disclosed herein is not intended to be 
limited to any particular terminology that expresses sim- 
ilar concepts. 

[0115] It is intended tiiat tiie foregoing detailed 
description be regarded as illustrative rather tiian limit- 
ing and ttiat it is understood tiiat the following claims 
including all equivalents are intended to define tiie 
scope of tiie invention. 

Claims 

1 . A method of forming a geographic database for use 
in a navigation system, wherein the geographic 
database includes a plurality of data records tiiat 
represent geographic features in a geographic 
region, tiie method comprising tiie steps of: 
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providing intermediate format files of different 
types, including a! least a intermediate format 
file of a first type and an intermediate format file 
of a second type, wherein each of the interme- 
diate format files is comprised of a plurality of 5 
data records that represent geographic fea- 
tures in the geographic region; 
parceliztng at least the Intermediate format file 
of the first type and the intermediate format file 
of the second type, wherein the parcelizing 10 
step forms a plurality of parcels of said interme- 
diate format file of the first type and a plurality 
of parcels of said intermediate format file of 
said second type, wherein each parcel includes 
a plurality of data records of said respective is 
type; and 

interleaving the parcels of said first type and 
the parcels of said second type. 

2. The method of Claim 1 wherein said geographic 20 
database is organized into a plurality of separate 
layers, wherein each layer includes a separate col- 
lection of data records based upon functional class. 

3. The method of Claim 2 wherein said of parcels of 25 
the first type and the parcels of said second type 
are interleaved together within one of said plurality 

of layers. 

4. The method of Claim 1 wherein the data records in so 
the parcels of the first type include data records that 
represent aggregations of segments of roads and 
routing characteristics associated therewith, and 

further wherein the data records In the parcels 3S 
of the second type represent segments of 
roads, and 

further wherein each of said data records in the 
parcels of the first type that represents an 
aggregation of segments of roads includes a 40 
reference to those data records in the parcels 
of the second type that represent the segments 
of roads that the data record in the parcel of the 
first type represents in aggregation. 

45 

5. The method of Claim 1 wherein the piurairty of data 
records in each of the parcels formed t>y said 
parcelizing step for each of the types represent 
geographic features that are encompassed within a 
separate one of a plurality of rectangular areas that so 
together encompass the entire geographic region. 

6. The method of Claim 1 forther comprising: 

forming a kd-tree to represent the parcelizing of ss 
one of the intermediate format files spatially. 

7. The method of Claim 6 forther comprising: 
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using the kd-tree when Interleaving to define an 
order by which the parcels of the first type and 
the parcels of said second type are interieaved. 

8. The method of Claim 1 wherein the parcels of the 
first type include data records that each include a 
reference to at least one data record in the parcels 
of the second type, and wherein said step of inter- 
leaving forther comprises: 

storing each of said parcels containing data 
records of said second type acQacent to those 
parcels containing data records of said first 
type that include data records that include ref- 
erences to the data records of said second type 
contained therein. 

9. The method of Claim 1 wherein said step of inter- 
leaving forther comprises alternating single parcels 
of said first type and single parcels of said second 
type through an entire layer of the geographic data- 
bas& 

10. The method of Claim 1 wherein the step of inter- 
leaving results in the interieaved parcels of said first 
type and parcels of second type being spatially 
organized. 

11. TTie method of Claim 1 further comprising the step 
of: 

providing instructions indicating a custom 
ordering pattern for interleaving the parcels of 
said first type and the parcels of said second 
type: 

and wfierein the interleaving step forther com- 
prises: 

interleaving the parcels of said first type and 
the parcels of said second type according to 
the custom ordering pattern. 

12. The method of Claim 1 forther comprising the step 
of: 

after interleaving the parcels of said first type 
and the parcels of said second typa forming a 
final format file with the parcels of said first type 
and the parcels of said second type concate- 
nated together. 

13. A geographic database for use in a navigation sys- 
tem, comprising: 

a plurality of data records of a first type; 
a plurality of data records of a second type; 
wherein the plurality of records of the first type 
are organized Into a plurality of parcels, 
wherein each parcel includes a plurality of data 
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records of said first type; 
wherein the plurality of records of the secorxJ 
type are organized into a plurality of parcels, 
wherein each parcel includes a plurality of data 
records of said second type; and 5 
wherein said parcels of data records of said 
first type are interleaved with said parcels of 
data records of said second type. 

14. The invention of Claim 13 wherein said geographic 10 
database is stored on a computer readable 
medium. 

15. The invention of Claim 13 wherein said geographic 
database Is organized into a plurality of separate is 
layers, wherein each layer includes a separate col- 
lection of data records based upon functional class, 
and wherein the parcels of data records of said first 
type are interleaved with the parcels of data records 

of said second type within one of said plurality of 20 
layers. 

16. The Invention of Claim 13 wherein the data records 
in the parcels of the first type include data records 
that represent aggregations of segments of roads 2s 
and routing characteristics associated therewith, 
and 

further wherein the data records in the parcels of 
the second type represent segments of roads. 

30 

17. The invention of Claim 16 wherein each of the data 
records in the parcels of said first type that repre- 
sents an aggregation of segments of roads includes 
a reference to those data records in the parcels of 
said second type that represent the segments of 3s 
roads that the data record in the parcel of the first 
type represents in aggregation. 

18. The invention of Claim 17 wherein said geographic 
database is organized into a plurality of separate 40 
layers, wherein each layer includes a separate col- 
lection of data records based upon functional class 
and 

wherein the parcels of data records of said first type 
are interleaved with the parcels of data records of 4s 
said second type within one of said plurality of lay- 
ers. 

19. The invention of Claim 13 wherein the parcels of 
data records of said first type and the parcels of so 
data records of said second type are spatially 
organized. 

20. The invention of Claim 13 wherein each of at least 
one of said parcels of data records of said second 55 
type is adjacent to at least one of said parcels of 
data records of said f orst type and that represent tiie 
same geographic features. 



21. Tlie invention of Claim 20 wherein the data records 
in the parcels of said first type include data records 
that represent aggregations of segments of roads 
and routing characteristics associated therewith, 
and 

further wherein the parcels of said second type 
include data records that contain abbreviated rep- 
resentations of segments of roads, 
and further wherein each of said data records in the 
parcels of said first type that represents an aggre- 
gation of segments of roads includes a reference to 
those data records In the parcels of tiie second type 
tiiat represent tiie segments of roads that the data 
record in tiie parcel of the first type represents in 
aggregation. 

22. The invention of Claim 21 wherein each of tiie data 
records in the parcels of the second type that con- 
tain abbreviated representations of segments of 
roads includes a reference to a data record in a par- 
cel of the first type tiiat contains a non-abbreviated 
representation of the same segment of road. 

23. The invention of Claim 13 wherein the parcels that 
contain data records of said first type include data 
records that each include a reference to at least 
one data record contained in a parcel containing 
data records of the second type, 

and wherein each of the parcels containing data 
records of said second type Is located adjacent to 
tiie parcels containing data records of said first type 
that include references thereta 

24. The invention of Claim 13 wherein the data records 
in tiie parcels of the first type include data records 
tiiat represent cartographic features and display 
characteristics associated therewith, and 

further wherein the data records in the parcels of 
the second type represent points of interest and 
characteristics associated therewitii. 
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